thbookfandomcom-20200214-history
Supplementary Specification
Introduction Purpose This document captures the system requirements of the that are not readily captured in the use cases of the Use Case Document . It also describes the requirements mentionned in the Vision Document in more details. Domain Logic This Section Describes the Theater domain logic in which the System is going to be implemented. The domain is a theater that organizes various types of events (concerts, comedy nights, etc.). An event contains a unique identification number, a title, a date and time that will take place, a maximum capacity (different events may take place in one of three halls of the theater) and it can be ‘open’ or ‘closed’ depending on whether bookings can still be made, or an event is fully booked. Events are stored in a catalog. There is a maximum of two shows per hall per day, over some weekend (Friday –Sunday). Actors of the domain are the stakeholders described in the Stakeholder Descriptions of the Vision Document. Domain Class Diagram To better represent the domain, the following domain model is provided : Domain ocl specification The domain logic is also enforced by the follwoing ocl specification : context Event: inv: self.ID -> isUnique() inv: self.bookings -> size() <= self.Capacity inv: self.capacity = self.bookings -> size() implies self.state = State::closed context Catalog: inv: allInstances() -> size() <= 1 Functionality This section describes the functional requirements of the system for those requirements which are expressed in the natural language style. Events Management #The System must allow Create operations on Events. #The System must allow Retrieve operations on Events. #The System must allow Update operations on Events. #The System must allow Delete operations on Events. #Create, Update and Delete operations can only be performed by an administrator. #Each operation must be able to run concurrently with other Event Management operations as well as bookings operations. Administration Mode #The System must define an Administration mode. An Administration mode is a password-protected mode in which administrators can perform events Creation, Retrieval, Update, and Deletion. Events Bookings #The System must allow Clients To book events. #Each booking must be able to be made concurrently with other bookings and Event Management operations. #Upon booking of a given event, non-administrator are just allowed to see the number of bookings already made for that event and the number of events that can still be made. Usability This section includes all of those requirements that affect usability. Required Training Time As the system will be made available to the general public on deployement, its user interface must allow the user to learn and navigate through the website without little or no training at all. As a fit criteria, the system's user interface will be put to an acceptance test/survey prior to deployment to a selected group of users in which 75% or more must find the system interface satisfactory. Reliability Availability The System must be available 100% of the time, excluding during maintenance operation. Mean Time Between Failures The mean time between failures must not be less than 1 year. ''Mean Time To Repair'' The mean time to repair the system must be no more than 2 hours. This is to increase customer and client user experience. Performance Transaction Response time In order to maximise user experience, the system must have an average response time of less than 5 seconds and a maximum response time of 30 seconds. As the application is a web application and the response time heavily depends on each user's Internet connection bandwith, we assume this requirement must hold true for each user running with a conncection of 512 kb/s or greater. Throughput Given the estimated daily number of clients/customer that access the system, the latter must allow for at least up to 500 transaction per seconds. Capacity The System must be able to accommodate a maximum of at least 10 000 customers, 10 000 clients, and 1000 events that can span over a period of at least 20 years starting from the date of the system deployment.